@wanderer o/ here is an update :) This is required me to make more changes than I hoped for, but things are getting ready and I'm feeling pretty happy about this "interface-ipld-format".

If you want to start hacking the js-ipld-eth-block, check ipld/js-ipld-dag-pb#1, it is pretty much there. I added you as a contributor to https://github.com/ipld/js-ipld-eth-block.

I'm going to continue and churn through the other things :)

@nicola I don't know how much you have seen of this, but this is important re the discussions we had in tr past two week. It seems this changes everything we planned for, so we have to start over again to a degree.

I don't think it's a drastic change, @diasdavid can you be in the call today?

I don't think it's a drastic change, @diasdavid can you be in the call today?
Add your review

Not in general, but in regards to the abstractions for the implementation I think it changes some things.

Update to the interface-ipld-format

By implementing dag-cbor, I realized that we only (and benefit from) having an interface for serialize, deserialize and cid detached from the format class. This enables raw json objects to be passed around like dag-cbor, without having to do an instance of a specific DAGNode cbor class. That being said, the new interface for an IPLD format resumes to:

• format.util
  • .serialize(dagNode) - returns a serialized version of this instance
  • .deserialize(<data>)- deserializes a binary blob into the instance
  • .cid(dagNode) - returns the CID of this instance
• format.resolver - the block level resolver (knows how to resolve paths at the block scope)
  • .resolve(block, path) - resolves a path in block, returns the value and or a link and the partial missing path. This way the IPLD Resolver can fetch the link and continue to resolve.
  • .tree(block, options) - returns all the paths available in this block

Another way to view it is that the main resolver doesn't really care what type does the 'deserialize' call return.

@diasdavid one other consideration (maybe its already been considered, im just still trying to grok) is that merkle links and the DAG topology / traversal should be independent of each other.

So for example, i would want to do something like

rootVertex.get(`/<ethereu, account hash>/`, account => {
   account.get('/balance/', (balanceVertex) => {
      console.log(balanceVertex.value) // how much ether this account has
  })
}) 

but underneath account doesn't have a true merkle link to balance. Its all part of the account blob. So account vertex has the edges balance, nonce, code, state. balance and nonce are just values. And code and state are merkle links.

@wanderer you can achieve that in two ways:

// resolve the account and get its object
resolver.resolve('/<ethereum account hash>/', '/', (err, result) => {
  const account = result.value
  // then manipulate the account as you already do
})

// or resolve the account balance, using the path notation

resolver.resolve('/<ethereum account hash>/', 'balance', (err, result) => {
  const balance = result.value
  console.log(balance.value) // how much ether this account has
})

we can go through this during today's js-ipfs chat :)

Getting close to that IPLD Week 2 goal :) An excellent way to achieve that is by CR the following PR:

Please, if you review it, remove the 'Needs review' label, so that work doesn't get duplicated.

//cc @victorbjelkholm @dignifiedquire @RichardLitt

MOVED TABLE TO: ipfs/js-ipfs#532 (comment)

@kumavis, @wanderer now you can git clone and npm install this repo without going through all the npm link hurdles, perfect time to test that new eth-block IPLD format :D

🎉